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REMARKS 

Claims 1, 10, 17, 26 and 33-34 have been amended. Claims 1-34 are 
pending. 

Claims 1, 17, 33 and 34 have been amended to clarify that the claimed 
method and computer system include determining whether a home condition 
exists so that the home of the object can be either included in or omitted from the 
representation of the object that is displayed. This amendment makes explicit 
what might have been seen as implicit before. Claims 10 and 26 are amended to 
correct a typographical error. These amendments are not seen to raise any new 
issues requiring further search or consideration, nor are they being made for 
purposes of patentability such that they would give rise to any estoppel under the 
principles of the Festo case law decisions. 

Figure 7 of the drawing has been amended to add labels YES and NO that 
were missing in these applications as filed. This revision is not believed to add 
new matter, as the processing flow is clearly described in the textual description 
of Figure 7. 

In the Office Action, Claims 10 and 26 were rejected under 35 U.S.C. § 
112, 2nd para, for reciting "transparent group" without antecedent basis. This 
phrase has been changed to "terminal group" as suggested in the Office Action. 
The Examiner is thanked for this helpful suggestion. 

The allowability of claims 9-10 and 25-26 is gratefully acknowledged. 
These claims have not been re-written in independent form, however, because it 
is believed that the independent claims from which they depend are allowable in 
view of the art of record, as described below. 

In the Office Action, claims 1-8, 11-24 and 27-34 are rejected under 35 
U.S.C. § 102(b) as being anticipated by Microsoft Windows NT, as evidenced by 
a printout of screen shots from what appears to be a 1998 version of this 
program (hereinafter "Screen Shots"). This rejection is respectfully traversed. 

Claim 1 recites a method of representing a resource in a computing 
system environment that includes (1) displaying a representation of an object on 
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a graphical user interface, the representation including the simple name of the 
object, (2) determining whether a home condition exists the representation of the 
object, (3) if a home condition exists, including the home of the object in the 
representation of the object, and (4) if a home condition does not exist, omitting 
the home of the object from the representation of the object. 

An illustrative example of output resulting from the method of claim 1 
appears in Figure 3 of the application as filed. A first object BIG BERTHA exists 
under the home HOSTS, and a second, same-named object exists under the 
home STORAGE. In the upper part of the display 380, the first BIG BERTHA 
object is shown with only its simple name (BIG BERTHA 357). In this case, the 
BIG BERTHA object is displayed under its home, so there is no need to include 
the home in the displayed representation of the object. In the middle part of the 
display 381, however, the first BIG BERTHA object is displayed along with the 
second BIG BERTHA object under the group UNIX. To avoid ambiguity, each is 
displayed with its respective home. For example, the first object is displayed as 
BIGBERTHA@HOSTS 357. Thus, the display of each of the BIG BERTHA 
objects is different in different parts of the display, depending on whether a home 
condition exists. 

As described in the application, this method provides for improved visual 
appearance of a display of a hierarchical collection of objects. Because the 
home of an object only appears where necessary (as dictated by the home 
condition, which may be for example that multiple objects with the same simple 
name are displayed at the same hierarchical location of the display), the display 
is relatively uncluttered but also unambiguous, i.e., objects having identical 
simple names are shown with their respective homes when necessary so that a 
user does not confuse one object for the other. 

Screen Shots shows different facets of the graphical user display in a 
Windows NT system as it pertains to certain types of objects. Figure 1 , for 
example, shows a flat (i.e., non-hierarchical) display of names of output ports in 
the "Properties" dialog window for a printer. Two different ports WUSPTO- 
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FMSHP-01\HPFAX and \\EFX1\HPFAX are shown. Figures 2-4 show the 
process by which the well-known "shortcut" is created, and Figure 5 shows a 
resulting shortcut icon. Figure 6 shows the shortcut residing in the "Desktop" 
folder. Figure 7 shows the presence of a folder within the "Desktop" folder. 
Figure 8 shows a pop-up menu of actions that can be taken with respect to an 
object, including "Send to" and "Rename". 

In the display of Figure 1 of Screen Shots, the two ports WUSPTO- 
FMSHP-01\HPFAX and \\EFX1\HPFAX have a common ending part, the string 
"HPFAX". This string does not refer to a single port displayed in two separate 
display areas, but rather simply forms the ending part of the names of two 
different ports. There is no indication that displaying the remaining part of each 
port name is somehow conditional. That is, there is no evidence that if the port 
named \\USPTO-FMSHP-01\HPFAX were the only one displayed, only the string 
"HPFAX" would be displayed. In fact, it is believed that Windows NT functions to 
the contrary. The Windows NT system displays the entire port name to identify 
each port - the name is not conditionally shortened to "HPFAX" depending on 
whether another port with a similar ending part is also displayed. It is believed 
that if the port "\\EFX1\HPFAX" were renamed to "\EFX1\CANONFAX", for 
example, or even deleted entirely, it would have no effect on the display of the 
port \\USPTO-FMSHP-01\HPFAX. That port would continue to be displayed in 
the same manner, even though any ambiguity that might be caused by the use of 
"HPFAX" would be absent. 

With respect to Figures 2-5 of Screen Shots, there is no indication that the 
shortcut for "autoexec.bat" is displayed differently depending on anything that 
can be characterized as a "home condition". In both Figure 5 and Figure 6, the 
shortcut is shown with only the name "autoexec.bat", with no other text 
(distinguishing or otherwise) included. Additionally, there is no situation in these 
figures in which displaying just the file name "autoexec.bat" creates any 
ambiguity - there are no other objects named "autoexec.bat" also displayed, and 
therefore no reason to do anything to distinguish one from the other. 
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It is respectfully urged that claim 1 is not anticipated by Screen Shots, 
because it fails to show all the elements thereof. Specifically, Screen Shots fails 
to show (1) determining whether a home condition exists for the representation of 
an object on a display, (2) if a home condition exists, including the home of the 
object in the representation of the object, and (3) if a home condition does not 
exist, omitting the home of the object from the representation of the object. 
There is no indication in Screen Shots that any such conditional processing and 
displaying occurs. In Figure 1 of Screen Shots, for example, there is no depiction 
of a condition that could be taken as a non-home condition, i.e., where referring 
to either of the ports \\USPTO-FMSHP-01\HPFAX or \\EFX1\HPFAX by using 
"HPFAX" alone would be unambiguous. Furthermore, there is no evidence that 
the manner in which the ports are displayed would be changed under any such 
circumstances, and in fact the opposite is believed to be true - the ports would 
be displayed the same way. With respect to Figures 2-5 of Screen Shots, which 
are specifically relied upon in the rejection of claim 1 , there is no indication that 
the shortcut for "autoexec.bat" is displayed differently depending on whether or 
not a "home condition" exists. In both Figure 5 and Figure 6, the shortcut is 
shown with only the name "autoexec.bat", with no other text (distinguishing or 
otherwise) included. Also, displaying just the file name "autoexec.bat" does not 
create any ambiguity - there are no other objects named "autoexec.bat" also 
displayed. Thus, Screen Shots does not show either a home condition or the 
displaying of a home along with an object representation if a home condition 
exists. 

Although the Office Action states that "since there is only one file with the 
same name in the current hierarchy, no home condition exists, therefore there is 
no need to display the home name of the object," this statement is seen to be 
misleading. Claim 1 does not read on a system that lacks the possibility of a 
home condition and therefore never displays a home of an object. Rather, it 
reads on a system that includes the possibility of a home condition occurring 
under some operating conditions, and (1) when it does, a home is displayed 
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along with the simple name of the object, and (2) when it does not, the home is 
omitted from the display of the object. Screen Shots does not describe such a 
system. 

Based on the foregoing, claim 1 is seen to be allowable in view of Screen 

Shots. 

It will be seen that the remaining claims incorporate, either directly or 
indirectly, the same elements of claim 1 discussed above, and therefore the 
remaining claims are also not anticipated by Screen Shots for at least the same 
reasons discussed above. 

With respect to claim 2, the statements in the Office Action are seen to 
further support what is stated above with respect to claim 1 . Taking the Desktop 
as the "home" of the "autoexec.bat" shortcut, as stated in the Office Action, it will 
be seen that the displayed representation of the shortcut does not include the 
string "Desktop". 

With respect to claims 3 and 1 9, Screen Shots does not show the use of a 
suffix to distinguish non-unique homes. If anything, the strings WUSPTO- 
FMSHP-01\HPFAX and \\EFX1\HPFAX could be viewed as prefixes , not suffixes. 
Moreover, the Office Action confusingly states that "Windows puts a prefix with 
the home location of the port." However, claim 3 recites assigning a suffix to a 
home if the home is not unique - i.e., the suffix and the home are separate 
things. The string \\USPTO-FMSHP-01\ cannot be both the "suffix" of claim 3 as 
well as the "home". 

With respect to claims 5 and 21, the ports \\USPTO-FMSHP-01\HPFAX 
and \\EFX1\HPFAX are displayed in only one context and are displayed only 
non-uniquely, and therefore there is no evidence that the manner in which these 
objects are displayed depends on either a context or uniqueness condition. 

With respect to claims 6 and 22, there is no indication in the Screen Shots 
that the home condition is established when a user indicates that objects are to 
be displayed in a qualified manner. 
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With respect to claims 1 1 and 27, Figure 6 of Screen Shots is not seen to 
represent any functional relationships among displayed objects. The items 
appearing in the "Desktop" folder do not relate to each other apart from being 
stored in the same folder, which can hardly be called a "functional relationship". 
Examples of displaying functional relationships from the present application are 
shown in Figure 3, for example, at ref. 382. Here, it is seen that BIGBERTHA is 
a PROJECT of the type MISSILES. It is also seen that the object 
MISSILES@PROJECTS is part of a USER GROUP called MORRIE'S GROUPS. 
Functional relationships such as these examples are not depicted in the Screen 
Shots. 

With respect to claims 12 and 28, it is respectfully submitted that Figure 6 
of the Screen Shots has nothing to do with managing storage area network 
resources. 

With respect to claims 13 and 29, as described above Figure 1 of the 
Screen Shots shows two different objects whose names both end with "HPFAX", 
not a single object. Furthermore, there is no indication that the context in Figure 
1 is a "non-home" context as opposed to a "home" context. 

With respect to claims 16 and 32, Figure 1 of the Screen Shots does not 
show a simple name followed by the home of the object, as in the example 
MISSILES@PROJECTS. Rather, it shows a function-indicating string HPFAX 
preceded bv another string that distinguishes it from other ports that utilize the 
same function-indicating string. 

In view of the foregoing, it is believed that all the claims of this application 
are allowable. Favorable action is respectfully requested. The Examiner is 
urged to telephone Applicants' attorney to resolve any issues that may be 
remaining. 

There is believed to be no fee required for this amendment. If the U.S. 
Patent and Trademark Office deems a fee necessary, this fee may be charged to 
the account of the undersigned, Deposit Account No. 50-0901 . 
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If the enclosed papers or fees are considered incomplete, the Patent 
Office is respectfully requested to contact the undersigned collect at (508) 366- 
9600, in Westborough, Massachusetts. 

Respectfully submitted, 



Jamei F. Thompson 
Attorney for Applicant(s) 
Registration No.: 36,699 

CHAPIN & HUANG, LLC. 
Westborough Office Park 
1700 West Park Drive 
Westborough, Massachusetts 01581 
Telephone: (508) 366-9600 
Facsimile: (508) 616-9805 
Customer No.: 022468 
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